As recognized in Revision 2.0 of the INTEL® Virtualization Technology Specification for the INTEL° ITANIUM® Architecture (VT-i), dated April 2005 (hereinafter “the VT-I Specification”), conventional operating system (OS) designs typically assume the OS has complete and direct control of hardware and system resources. The OS implements the policies to manage these resources to allow multiple user-level applications to be run. The goal of virtualization is typically to allow multiple instances of OSs to be run on a system. The OSs can be same or different versions, and can come from different OS vendors.
In a typical virtualized environment, there will be a piece of system software responsible for virtualizing the hardware and system resources to allow multiple instances of the OSs to be run. The software component that provides such functionality is referred to herein as the virtual machine monitor (VMM). The VMM is typically a piece of host software that is aware of the hardware architecture.
For each instance of guest OS, the VMM creates and presents a virtual machine (VM) to the guest OS. From the perspective of a guest OS, the VM includes all the hardware and system resources (e.g., processors, memory, disk, network devices, etc.) expected by the guest OS. From the VMM perspective, these hardware and system resources are “virtualized.”
For example, a VMM may create a VM that presents two logical processors to one guest OS, and a VM that presents one logical processor to another guest OS. The actual underlying hardware, however, may include less than, equal to, or greater than three physical processors. The logical processors presented to a guest OS are called virtualized processors. Likewise, VMs may include virtualized storage, peripherals, etc.
The VT-i Specification and a corresponding specification dated April 2005 for the IA-32 INTEL® architecture (the VT-x Specification) may be obtained from the URL located at http:- -www.intel.com-technology-computing-vptech-, where the “/” character has been replaced in the URL with the “-” character to avoid an active hyperlink from within this document.
Virtualized environments include fully virtualized environments, as well as paravirtualized environments. In a fully virtualized environment, each guest OS operates as if its underlying VM is simply an independent physical processing system that the guest OS supports. Accordingly, the guest OS may expect or require the VM to behave according to the architecture specification for the supported physical processing system. By contrast, in paravirtualization, the guest OS helps the VMM to provide a virtualized environment. Accordingly, the guest OS may be characterized as virtualization aware. For instance, a paravirtualized guest OS may be able to operate only in conjunction with a particular VMM, while a guest OS for a fully virtualized environment may operate on two or more different kinds of VMMs.
A VMM may use emulation to perform certain operations on behalf of a guest OS. For instance, the guest OS may include an instruction to access a register. However, since the register will reside in a virtualized processor, the VMM may need to emulate the access for the guest OS.
One approach for supporting virtualization involves hardware assistance or acceleration for emulating guest operations. However, certain types of processors may lack the control logic needed to provide hardware assistance for virtualization, and other types may provide hardware assistance to emulate some guest operations but not all guest operations or instructions that need to be emulated.
When hardware assistance is not available or not sufficient to handle all emulation requirements, other approaches may be used, including emulation techniques that use code patches which cause interrupts, exceptions, faults, and the like (referenced generally hereinafter as faults). For example, to facilitate emulation of certain operations, a VMM may apply patches to insert new code into code being executed by a VM. Specifically, the patches may augment or replace existing code. For instance, the VMM may replace old code with new code while keeping with original code size, so that it is not necessary to relocate the whole binary. Each patch, when executed, may cause the processing system to generate a fault.
For purposes of this disclosure, the term “emulation patch” refers to a patch that is applied to code of a guest VM, to facilitate the emulation of operations for the guest VM. Emulation patches may be applied statically or dynamically. To handle a fault triggered by an emulation patch, a conventional processing system saves and eventually restores the contextual data that defines or constitutes the system state for the guest VM. That contextual data may be called the trap frame.
An emulation patch may include or consist of a pseudo instruction. For purposes of this disclosure, a pseudo instruction is an instruction that is undefined or that includes an invalid argument or value. Consequently, when a pseudo instruction from an emulation patch (i.e., a patched pseudo instruction) is executed, it will trigger a fault (e.g., an illegal operation fault). Reserved fields or other special instructions may be used as pseudo instructions.
According to conventional approaches for supporting virtualization, each of the emulation patches, when executed, may cause the processing system to save and restore the trap frame. It may be necessary to save the trap frame because some or all of the software used to handle emulation of the guest instruction may have been written in a high level language, such as C. Unfortunately, saving and restoring the trap frame may take many hundreds of instruction cycles.
In addition, as described below, an exception handler in the VMM may perform a complex series of operations to determine which guest instruction corresponds to the pseudo instruction that caused the fault, and to then emulate that guest instruction. Consequently, conventional emulation patches may have a significant impact on performance.